Montaje y pulido de niveles

1. Sesión 1

1.1. Profesor

• Carlos León <cleon@ucm.es>
• Profesor FdI
• Docencia MVJ: Arquitectura UE, prácticas diseño de niveles, tutor de proyectos
• Videojuegos, Creatividad Computacional y Sistemas Cognitivos
• Grupo de investigación NIL
• Despacho 444 FdI

1.2. Introducción y objetivos

1.2.1. Motivación

Uno de los roles más comunes en el diseño de videojuegos es el de creación de mapas/niveles, este módulo está pensado para reforzar vuestra habilidad como creadores de estos contenido

1.2.2. Objetivos

Saber crear de principio a fin niveles con una buena base técnica (objetivo, ideación, despliegue, comprobación…)

1. Poner en práctica la teoría para crear niveles (y no sólo mecánicas o lógica)
2. Pulir nivel para jugabilidad y objetivos
3. Hacer QA útil y aplicarlo

1.2.3. El nivel concreto

La ideación abstracta de mecánicas y dinámicas se vuelve concreta cuando hacemos nivel:

• Distancias
• Tiempo
• Objetos
• Enemigos

1.2.4. Niveles

• Un scroll lateral de saltos
• Un top-down dual-stick
• Un FPS

Las implementaciones disponibles ya os la damos hechas

No hace falta que cambiéis nada, pero no está prohibido

Están basadas en contenido core de UE para facilitar documentación y modificación

1.2.5. Grupos

Haremos las prácticas en grupos de 2 o 3 personas

Tenéis libertad para crear grupos, pero los equipos en los que se combine capacidad de programación con capacidad de diseño, generalmente, funcionarán mejor

1.3. Cómo hacer cada nivel

1.3.1. Ideación

Aparte del nivel implementado, un documento que describa:

• concepto y objetivo del nivel
• referencias en las que nos basamos
• las dinámicas buscadas
• las mecánicas con las que se intentan conseguir
• la estética con la que se comunica
• las métricas de nivel y juego (qué se va a medir)

1.3.2. Concepto de nivel

Ayuda mucho dar un concepto único de nivel:

• Objetivo de nivel: ¿para qué es este nivel?
• Idea base: ¿qué idea queremos desarrollar sobre él?
• Desafío base: ¿qué es difícil en el nivel?
• Evolución: ¿cómo es el desenlace del nivel?

1.3.3. Prototipo I

Implementación del MVP con las ideas principales

Si se van a introducir mecánicas, éste es el momento

1.3.4. Pruebas I

Los desarrolladores no sirven como sujetos de prueba

• ¿Está presente el concepto que buscamos?
• ¿Se cumple el objetivo de nivel?
• ¿Se trabajan obligatoriamente las mecánicas?
• ¿El jugador hacer lo que esperamos?
• ¿Se entiende lo que queremos expresar?

Las primeras pruebas deberían servirnos para descubrir cuál es el funcionamiento general del nivel con usuarios externos

1.3.5. Prototipo II

A partir de los datos de las "Pruebas I", generamos un nivel "feature complete", con todo lo que buscamos, aún sin pulir métricas

Pero preparado para sacar datos y pulir

Si se van a introducir elementos estéticos, lo ideal es hacerlo aquí

1.3.6. Pruebas II

• ¿La duración es apropiada?
• ¿El jugador muere las veces que buscamos?
• ¿Cuántas veces intenta el punto X?
• ¿Hay vida/balas/tiempo suficientes?
• ¿En qué puntos hay conflictos y el jugador se atasca?

1.3.7. Prototipo final

Todo terminado y pulido

Las variables tienen los valores ya ajustados, y hemos aplicado los cambios de las Pruebas I y II

1.3.8. Pruebas finales

El juego es "el ideal", y ahora vamos a comprobar que se cumplen

La conclusión tiene que ser:

He comprobado que en mi nivel ocurre lo que yo quería que ocurriera

Tras cada prototipo final, se hará una presentación del desarrollo en clase

1.3.9. Pruebas de esfuerzo y pruebas de gameplay

Dos tipos de pruebas:

• Intentando "romper" nivel o gameplay: speed run, no matar a nadie, escaparse, encontrar defectos
• Jugar de la manera más natural, sin intentar saltarse las normas

Ambos tipos de pruebas son importantes y necesarios, y nos dan información complementaria sobre el nivel

1.4. Notas de implementación

1.4.1. Mando

Aunque no es estrictamente necesario, se pueden traer mandos (gamepads) para probar los juegos, principalmente para el dual-stick

1.4.2. Edición de parámetros

Todos los parámetros de personajes, nivel y demás que se puedan usar para equilibrar están puestos en la categoría "Game" en UE

1.5. Entrega

Un .zip, enviado por correo electrónico, con:

• Un PDF con la documentación y nombres del equipo (un solo documento para los 3 niveles)
• El proyecto de UE con la implementación

1.5.1. Qué incluir en el informe final

• Resumen de diseño
• Mecánicas cambiadas
• Mapas en texto
• Plan de pruebas
• Ejecución de pruebas y resultados
• Datos de pruebas
• Resumen de experiencia con otros juegos

Y, en general, todo lo relevante y todo lo que hemos ideo apuntando

La idea es que la entrega sea el material que se ha hecho en clase (con algunas mejoras donde tenga sentido)

El objetivo es no quitaros más tiempo de lo necesario fuera de las sesiones

La entrega se hará 14 días después de la última sesión

Recordad: intentad enviar lo que se ha hecho en clase (lo podéis retocar después), no es necesario avanzar mucho más los niveles

1.6. Cómo crear los niveles

1.6.1. Whiteboxing (recordatorio)

Whiteboxing (también greyboxing, block out, brushes o brush actors) es el proceso de crear los volúmenes de un nivel, sin tener en cuenta los detalles (las mallas 3D)

Es el borrador de un nivel, en el que crearemos y experimentaremos con es espacio, distancias, tamaños, etc

Es una técnica muy buena para saber qué se quiere antes de "vestir" el nivel entero:

• Podremos iterar rápidamente (sin esperar al contenido artístico)
• Nos permite "aislarnos" de la parte estética
• Podemos probar las mecánicas y dinámicas

1.6.2. Whiteboxing en UE

Veamos algunos aspectos básicos para crear geometría en UE

(Más información en la documentación de UE)

1.6.3. Manipulación directa

1.6.4. Colisión

En teoría se puede cambiar la colisión con solidity, pero no funciona bien

1.6.5. Edición de geometría

1.6.6. Operaciones booleanas

1.6.7. Colores en whiteboxing

Es muy útil añadir colores (materiales) a los bloques para indicar su semántica:

• Verde: seguro
• Rojo: dañino
• Amarillo: objetivo
• Azul: objeto

1.6.8. Información adicional

1.7. Scroll lateral

1.7.1. Introducción

En esta parte se va a trabajar en la creación de un nivel para un juego de mecánicas clásicas y sencillas de arcade desplazamiento lateral

Sigue un sistema básico 2D en un nivel de desplazamiento abierto (se puede ir a cualquier parte dentro de la zona delimitada)

1.7.2. Celeste

• Exigencia muy alta de nivel
• Pero muy poco castigo al fallar
• Poca rejugabilidad (si tienes mucho nivel, el principio es muy fácil)
• Añade mecánicas + elementos de nivel
  • Doble y triple "salto" buenos para corregir

1.7.3. Super Mario World

• SMW tiene infinidad de enemigos y mecánicas que van evolucionando
• Mucho contenido, mucho opcional (rejugabilidad de niveles)
• Habilidad de movimiento
  • No hay doble salto, hay que hacerlo bien a la primera
• En general hay tiempo de sobra

1.7.4. Super Ghouls 'n Ghosts

• Salto sin movimiento: es importante, en un side-scroller, que nos podamos mover durante el salto. Es irreal, pero evita que tengamos que planificar un salto y da más velocidad al juego (y posibilidades)
  • Hay un doble salto que permite corregir
• Añade disparo/mecánicas lucha
• Mecánicas muy constantes

1.8. Elementos y mecánicas de la práctica

1.8.1. Desplazamiento

Desplazamiento lateral sencillo (izquierda/derecha), a una velocidad parametrizable

1.8.2. Agacharse

El personaje puede agacharse, reduciendo su altura a un multiplicador (parámetro)

1.8.3. Salto

Salto sencillo, de altura parametrizable

Es posible añadir movimiento lateral al salto (es decir, cambiar la dirección en el aire), parametrizable respecto a la velocidad básica en el suelo

1.8.4. Varios saltos

En el atributo Possible jumps se puede cambiar el número de saltos que se pueden dar en el aire (1, 2, 3…)

1.8.5. Coger y lanzar objetos

Para cambiar la potencia de lanzamiento, se puede cambiar la variable Throw strength

1.8.6. Daño

Tenemos \(N\) puntos de vida (configurable como Life, puede ser que \(N=1\)), y el contacto con los enemigos que no daña nos resta puntos

El daño en configurable en el atributo Damage

Para cambiar la vida inicial, tenemos la variable Life (en el componente Damageable)

1.8.7. Caídas

Si caemos por un agujero, perdemos todos los puntos de vida y la partida se reinicia (blueprint Deep)

1.8.8. Gemas

Las gemas son coleccionables para el jugador

Se pueden usar como objetivo (maximizar gemas cogidas), o como condición para eventos

1.8.9. Pulsadores

Al ser tocados, un elemento del escenario desaparece (¿una barrera?)

Es configurable en el atributo Barrier

1.8.10. Vigía

El vigía va hacia derecha o izquierda hasta que se tope con un obstáculo (y entonces se da la vuelta) o hasta que caiga de una plataforma a otra inferior (y sigue moviéndose) o al vacío, y muere

1.8.11. Eliminar enemigos

Podemos eliminar enemigos de varias formas (cada golpe puede tener hacer distinto daño):

• Haciendo que caigan en trampas (ver 1.8.10)
• Lanzándoles objetos que les dañen

Cuando un enemigo es eliminado, desaparece de la escena

1.8.12. Fin del nivel

1.8.13. Objetivos

• Crear un nivel de scroll lateral
• Nivel "lineal" (no necesariamente la geometría, pero sí el desarrollo: no se pasa 2 veces por un sitio)
• Todas las mecánicas deberán ser usadas en el nivel
• Justificar y explicar las razones y el impacto en el jugador de cada decisión de diseño

1.8.14. Habilidad

Buscamos un gameplay que explore la habilidad de control en los juegos

1.8.15. Cosas que poner en práctica

• Gestión de tiempo de nivel
• Bloqueo de avance con geometría/bloqueo
• Desafío y distancias salto/alcance, midiendo dificultad
• Ritmo desafío/descanso
• Muestra de desafío y solución (enseñar bloque y enemigo antes de resolver)

1.8.16. Dificultad y castigo

• Dificultad: nivel requerido para superar un desafío
• Castigo: penalización por no superar el desafío

Hay que gestionar la frustración generada por castigo y dificultad para mantener el desafío sin perder al jugador

1.8.17. Opcional

• Doble salto (parametrizable con el atributo Possible jumps)
  • Que el segundo salto sea más corto
• Es posible modificar, añadir o quitar mecánicas, pero siempre de forma justificada y consultándolo antes. El juego deberá ser fundamentalmente el mismo

• Hacer un nivel más largo, o más niveles
• Comparativa detallada con otros niveles de juegos con mecánicas comparables
• Que la velocidad del jugador dependa de si lleva o no un objeto
• Añadir tiempo (variables Time y HasTime en el game mode)

1.8.18. Prototipo I, pruebas I

2. Sesión 2 (scroll lateral): Prototipo II, pruebas II

3. Sesión 3 (scroll lateral): Prototipo final, pruebas finales, presentación

4. Sesión 4: Dual-stick cenital

4.1. Zelda

• Mecánicas que avanzan y desbloquean mundo y gameplay
• Lucha sencilla, principalmente cuerpo a cuerpo: encuentros por áreas
• Ritmo lento, enfrentamiento basado estrategia
• Puzzle, laberinto, descubrimiento

4.2. Enter the Gungeon

• Armas y balas por todas partes
• Dificultad creciente
• Sensación arcade (si juegas muy bien, los recursos no importan tanto)
• Pulido muy detallado
• Generación de mapa

4.3. Hades

• Diferentes estilos de juego según armas (no hay armas en el nivel)
• Influencia de varios géneros (Diablo, roguelikes)
• Gestión de avance en mazmorra
• Economía de recursos y mejoras para avanzar
• Core loop moderno, con mejoras y narrativa
• Narrativa por profundidad de nivel

4.4. Gauntlet

• Pantalla compartida: tiene que haber sitio para todos
• "Infinitos" enemigos
• Spawners
• No hay munición, pero hay "comida" y "pociones"
• La vida es el recurso principal

4.5. Objetivos

1. Hacer un nivel por habitaciones
2. Hacer una mazmorra sin habitaciones (todo seguido)

4.6. Estrategia

Buscamos un gameplay en el que el jugador planee su movimiento y sus acciones, de forma más o menos inmediata (tenéis libertad para decidir)

4.7. Cosas que poner en práctica

• Layout inicial de enemigos por zonas
• Dinámica llave-puerta
• Comportamiento de enemigos: ¿cuándo atacan?
• Diferentes enemigos y combinaciones
• Despliegue de recursos vs. despliegue de desafíos
• Zonas opcionales

4.8. Contenido y mecánicas

4.8.1. Descripción

Juego top-down, dual-stick en el que hay que atravesar una "mazmorra" de habitaciones

4.8.2. Movimiento

Movimiento WASD /palanca izquierda, se apunta con flechas de dirección o palanca derecha

4.8.3. Vida

Tenemos una serie de puntos de vida, como en el juego de scroll lateral

El daño funciona de la misma manera

Al recibir daño, hay un pequeño empuje configurable en PushDamage

4.8.4. Armas

Tenemos varias armas posibles

4.8.5. Arma básica

El arma normal tiene poca potencia y tiene munición infinita

4.8.6. Shotgun

(Todos los juegos necesitan una)

Cadencia de disparo baja, poca munición y ataque de dispersión

4.8.7. Machine Gun

Más munición, cadencia de disparo muy alta

4.8.8. Disparo y recarga

Hay munición global por cada arma, y munición en el cargador

Cuando se agota el cargador hay que recargar (activamente)

El tiempo de recarga (único para todas las armas) se encuentra en Recharging time

Cada arma hace un daño específico que puede configurarse en Weapon damage

En la clase del jugador hay varios Maps usados para configurar las armas:

• MaxMagazine (las balas que caben en cada cargador)
• Weapon fire rate (cadencia de disparo por arma)
• Has (las armas que tiene)

4.8.9. Enemigos

Los enemigos se mueven a través de una malla de navegación (NavMesh)

Hacen un daño Damage done, en la clase Enemy (clase padre)

4.8.10. Zombie

Te persigue y hace daño cuerpo a cuerpo

Se mueve mediante un árbol de comportamiento (que os explicarán más adelante)

En ShootTask está Distance threshold para la distancia a la que ataca

También Attack period que es el tiempo entre ataques

En los zombies hay también un parámetro llamado Distancia de deteccion que permite establecer la distancia del personaje principal a la que se activan

4.8.11. Pinchos

Si los tocas, te hacen daño

4.8.12. Powerups

Se pueden coger un power-ups que cambia la velocidad (Speed thing) durante Super speed time segundos en Super speed quantity

4.8.13. Puertas cerradas

Solo se pueden abrir con una llave (ver más adelante)

4.8.14. Recursos

• Vida
• Llave
• Balas

4.8.15. Portal

El nivel se acaba en el portal, igual que en juego 2D

4.9. Opcional

• Power-ups de invulnerabilidad y de potencia de disparo (u otras cosas)
• Dash
• Más enemigos
• Tipos de llaves
• Más armas (cuerpo a cuerpo, por ejemplo)
• Habitaciones/nivel procedimental

5. Sesión 5 (dual stick): Prototipo II, pruebas II

6. Sesión 6 (dual stick): Prototipo final, pruebas finales, presentación

7. Sesión 7: Shooter en primera persona

7.1. DOOM

• Ritmo, batalla: pasillos y habitaciones
• Hay narrativa, pero secundaria (texturas, enemigos)
• Arquitectura sin realismo, hay arcade
• Recursos: muchas balas, muchas armas
• Se juega a "matar bichos"
• Poca evolución de mecánicas: evolución de nivel

7.2. Might and Magic

• Mapa es fundamental (mazmorras)
• Versiones evolucionan hacia "FPS", pero mantiene rol: adaptación al movimiento
• Al desaparecer turnos, el descanso del jugador está en el mapa (ya no puedo esperar)

7.3. Halo

• "30 seconds of fun"
• Dinámicas de combate complejas y muy depuradas: mapa acompaña
• Mecánicas adicionales (conducir, torretas), bien posicionadas
• Tipos de armas para enemigos, hay recursos por el mapa y en los enemigos
• Diseño detallado de terreno y enemigos

7.4. Half-Life

• Flexibilidad de armas, pero cada arma está pensada para un enemigo
• No hay demasiada munición (pero sí de sobra)
• Puzzles
• Entorno y narrativa potentes
• Juego con saltos y físicas

7.5. Skyrim

• El control ya no es preciso en cuerpo a cuerpo
• Aparece control preciso "lento" con arco
• Relación mundo/personaje que elimina arcade y crea exploración
• Fusión 1ª/3ª persona (mismas mecánicas porque no importa precisión)

7.6. Portal

• Reinvención de puzzles en 1ª persona
• Físicas y ritmo lento
• Juego de cámara e información constante
• Niveles puzzle muy complejos que funcionan en 1ª persona

7.7. Objetivo

Hacer un nivel FPS

El escenario será continuo, pero habrá 3 "zonas" o entornos diferentes

Nos faltarán modelos para diferenciar el entorno, pero lo sustituiremos con formas geométricas claras (brushes)

7.8. Percepción

En este nivel vamos a jugar con las dinámicas de percepción del entorno, y cómo se reacciona ante ellas

• ¿Cómo informamos a nuestro jugador?
• ¿Cómo le ocultamos información?

7.9. Cosas que poner en práctica

• Línea de visión
• Geometría "realista", tamaños y espacios plausibles
• Flujo de acción con geometría
• Equilibrado acción-descanso (checkpoints)
• Guiado del personaje
• NPCs
• Narrativa

7.10. Juego

Las mecánicas van a ser las mismas que en el top-down, pero esta vez en primera persona

De hecho, puede ser interesante reutilizar las mecánicas que posiblemente hayáis añadido y comparar

El jugador aquí podrá también saltar (pero aquí no tiene más de un salto)

7.10.1. Pasar elementos de un proyecto a otro en UE

7.11. Comparación 2D-3D

• ¿Cómo cambian los valores entre primera persona y top-down?
• ¿Cómo cambia la percepción del entorno?
• ¿Gestión de enemigos y ataque?
• ¿Me pierdo?
• ¿Funciona la misma geometría?

7.12. Narrativa

7.12.1. Las historias

El valor de las historias en la experiencia de un videojuego es (como en casi todo) muy grande

Por tanto, vamos a contar, en nuestro nivel, una historia

7.12.2. Personajes no jugador (NPCs)

En el proyecto hay ahora un blueprint NPC

Este componente tiene una componente de tipo TextRender que contiene un atributo Text que se mostrará cuando el jugador "hable" con el actor

Además, el texto se activa automáticamente cuando estamos a menos de Talking distance (distancia, en el personaje principal) y el texto dura Show time segundos en pantalla (en el NPC)

7.12.3. Enlazar geometría e historia

Vamos a usar un esquema clásico principio-nudo-desenlace (aunque si encontráis una razón buena para otro esquema, adelante)

La geometría tiene que encajar con la narrativa contada

7.12.4. QA en la narrativa

• ¿Se entiende la historia?
• ¿Emociona la historia? ¿Qué emoción?
• ¿Mejora la experiencia? ¿Cómo?
• Preguntad por la percepción de tiempo, ritmo y evolución con y sin historia

8. Sesión 8 (FPS): Prototipo II, pruebas II

9. Sesión 9 (FPS): Prototipo final, pruebas finales, presentación